Skip to content

Fix Makefile bare export leaking all variables to subprocesses#4653

Open
tuxerrante wants to merge 1 commit intomasterfrom
tuxerrante/makefile-variable-expansion-fix
Open

Fix Makefile bare export leaking all variables to subprocesses#4653
tuxerrante wants to merge 1 commit intomasterfrom
tuxerrante/makefile-variable-expansion-fix

Conversation

@tuxerrante
Copy link
Copy Markdown
Collaborator

@tuxerrante tuxerrante commented Mar 5, 2026

Summary

  • Remove the bare export directive from the Makefile that was exporting every Make variable into the environment of every subprocess, causing potential slowness and unexpected behavior
  • Consolidate the redundant .env file (containing only PYTHONPATH) into the existing env file and env.example

Why some contributors experienced multi-minute make invocations

The bare export exported all Make variables — including ones defined with recursive expansion (=, ?=) containing $(shell) calls (git describe, git rev-parse, go env, etc.) — to every subprocess. Contributors with heavier shell startup (zsh + oh-my-zsh/compinit, nvm, conda) paid that cost on each $(shell) invocation. On fast setups with minimal bash the overhead was imperceptible, masking the issue.

The tunnel target also used $(shell az ...) which ran az at Makefile parse time on every make invocation, not just when make tunnel was called. This is now a recipe-level $$(az ...) call.

Test plan

  • make commands expect you to manually source the env file as per the docs

Copy link
Copy Markdown
Collaborator

@mrWinston mrWinston left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of things:

  1. I believe sourcing the env file automatically in the Makefile is conceptually flawed. It just increases complexity of our make-targets. Targets can't assume anymore that the caller has already sourced the required env file. Also, using different env files will be more complex.
  2. It looks like this PR reorders stuff in the env file without reason. This makes reviewing harder and actually introduced a bug. Please make sure that the changes are actually minimal.
  3. This RP seems to add additional configuration to the default env file. I would like to see this in a separate PR to address these changes separately. They don't seem related to the issue ourlined in the PR title and make reviewing harder
  4. Adding the env file to git can cause issues overwriting existing local configuration. Also, having a file both ignored and added is pretty confusing and surprising. And both are bad for our dev tooling.

Remove `-include .env` and bare `export` which leaked every Make
variable into recipe shells. Replace with a scoped `PYTHONPATH ?=`
default so Python targets work without manual sourcing.

Add PYTHONPATH to env.example for discoverability.
@tuxerrante tuxerrante force-pushed the tuxerrante/makefile-variable-expansion-fix branch from afa4a52 to 51becbd Compare March 5, 2026 13:40
@tuxerrante
Copy link
Copy Markdown
Collaborator Author

tuxerrante commented Mar 5, 2026

A few clarifications:

  • .env file was not part of .gitignore, which seems a pre-existent bug
  • env /env.example file needs some ordering and linting in my opinion, something should fail when values are not the ones expected (eg: Rename CLUSTER env var to CLUSTER_NAME for consistency #4656 in my local tests the cluster creation was failing because in the util pkg we expect a variable that doesn't exist in the dev.example)

Tried with shellcheck but doesn't catch it. It sees that LOCATION is assigned somewhere in the file and considers it valid. It doesn't do order-sensitive analysis because the variable could also come from the environment.

@tuxerrante tuxerrante requested a review from mrWinston March 5, 2026 13:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants